Article: SOA Governance: An Enterprise View

In a new article, SOA architect Michael Poulin explains the necessity for SOA governance to ensure an SOA initiative's success, and explains the role the OASIS SOA Reference Model and the accompanying SOA Reference Architecture assign to SOA Governance. Michael observes SOA governance specifics from the enterprise perspective and illustrates them with several examples of SOA Governance policies.

In addition to the SOA Reference Model, Michael introduces the OASIS SOA Reference Architecture, currently in public review:

The SOA RA PRD 1 has recognised the role of enterprise social structure within SOA. Indeed, actions of the participants of the service interaction – service consumers and providers – have business or technical meaning only to the people and organisational units “with needs” and those “with capabilities”. As a consequence of this, we may say that if a social structure changes, the same actions may get different meaning than before. Even more, if a consumer expects the same meaning of the service actions in different social structures, it is likely that the service has to behave differently and provide different results (or RWE) in different social structures to meet such expectation.

Michael points out that SOA Governance is not the only governance an enterprise has to be concerned with:

Nevertheless, SOA Governance does not replace Enterprise Governance, or Business Governance, or IT Governance. We have to remember that there is a world besides SOA.

According to the author, SOA Governance applies to four major aspects of service structure and service use:

Service structure – the minimal set of elements that constitute a service within element relationship and operational models (development, integration and deployment policies)

SOA infrastructure – the “plumbing” that provides utility functions that enable and support the use of the service (deployment and run-time policies)

Service inventory – the requirements on a service to permit it to be accessed within the infrastructure via public interfaces, manually and automatically (management policies)

Participant interaction – the consistent expectations with which all participants of the service interaction are expected to comply (reachability and run-time policies)

Michael concludes with examples of SOA Governance policies that have proven to be useful to him in the past:

Areas of Applicability	Policy Examples
Governance Process	Service Governance Roles include: Service Owner, Service Provider, Service Consumer, Service Steward, Service Registrar, etc. Service Governance Board includes representation from business, architecture, delivery and systems operations groups. The governance group is responsible for: Defining and maintaining governance directives and policies Granting of design and implementation exceptions when possible Compliance reporting to the Management. Governance policies and controls may be monitored and enforced by the Service Registrar as well as by corresponding Review Boards and Architectural Bodies
Development Stage	Design and development of the service has to have very strong reason(s) to be allowed going with an exception from the policies compliance Service design has to be based on and take into consideration business execution context of the required business task. The business execution context should be able to outline what elements of the service are likely to be changed in the future. Service design has to consider recommendations on the business operational scenarios for those who might use the service. If such scenarios are identified, business approval and sign-off are required. Services should minimise or totally hide their internal constraints from the consumers. A Service has to compensate for internal problem processing transparently to the consumers and never expose its internal execution constraints on to the consumers. Service interfaces and service body (implementation) must adhere to the corporate security policies The Service owner must provide service classification (business, infrastructure, etc.) and scope definition (business unit, enterprise, external, etc.) for each released service “Avoid setting up processes that demo well for three services without considering how it will work for 300” (SOA RA PRD 1).
Production Stage	All business services are required to maintain a Service Contract for each consumer they support. All services are required to publish Service Descriptions If the service does not require a Service Contract, its service level agreement has to be published in the Service Description All services are required to adhere to a versioning strategy that provides all consumers with opportunities to migrate to the latest supported version(s) of a service. All Service Descriptions have to be published in the Service Description Repository All run-time service policies have to be published in the Service Policy Repository Run-time service Policies may refer to other policies. Policies may be applied by the Policy Enforcement Point (PEP) interceptors and enforced by the Policy Decision Point (PDP) mechanisms “…consider whether the display of status and activity for a small number of services will also be effective for an operator in a crisis situation looking at dozens of services, each with numerous, sometimes overlapping and sometimes differing activities” (SOA RA PRD 1)

Check out Michael Poulin's article, "SOA Governance: An Enterprise View" for more information.

InfoQ Software Architects' Newsletter

Login with:

Don't have an InfoQ account?

Write for InfoQ

Rate this Article

This content is in the Cloud Computing topic

Related Topics:

Related Editorial

Related Sponsored Content

Popular across InfoQ

How could we improve? Take the InfoQ reader survey

The InfoQ Newsletter